In the telecom device management system, the line diagnosis is a very important function. When fault occurs at a line or the routine maintenance and detection is performed on the line, it is required to perform the diagnosis on the line. If it is diagnosed that fault occurs at a line, then the specific fault information is fed back to the user to instruct the user for trouble shooting, and make the line normal.
In the actual use, lines and terminal devices used in different countries and regions may be different. By taking the voice line as an example, the telephone lines and the telephones used in different countries and regions may be different, so the line diagnosis cannot be analyzed and judged in accordance with a unified standard when the diagnosis is performed on the lines. The line diagnosis often needs to differentially be treated according to physical characteristics of the actual used lines and terminal devices, that is, to be customized according to the actual situations.
For those above problems, there are two solutions in the related art. One solution is to perform custom development in the diagnosis program of the diagnostic apparatus in accordance with the actual situations. The method can achieve the function customization, but the time period is relatively long and cannot respond to changes in time. When the diagnosis apparatus is required to use in a particular area, it is required to make full investigation to understand all lines and terminal situations of the area, and complete the procedures, such as, custom development, testing, releasing, etc., before the deployment, so the whole period is longer. When a new line or terminal device type or a line or terminal device type omitted in the previous investigation appears after the deployment, it may be required for this change to re-perform the procedures, such as, custom development, testing and releasing, etc., and re-deployed a new software version or a patch to the field after the new software version or the patch is released. The method cannot satisfy the field requirements quickly, while it needs to wait for a long time before completing the customization, which often causes the grievances of the user and even complaints.
The other method is to use a configuration file, and put the physical characteristic parameters of the lines with the differences into the configuration file, and read the parameter values in the configuration file by the diagnostic program to perform the analysis and judgment. After the field deployment, the parameter values in the file are adjusted according to the field conditions. The method can achieve the rapid customization to a certain extent. However, the configuration file can only store specific data, while cannot contain the judgment logic. That is, it only can achieve the customization of the specific data, and the judgment logic in the diagnostic apparatus is still in the diagnosis program. When the judgment logic is required to be customized according to the field situation, the diagnostic program still needs to be modified and re-deployed to the field after a new software version or a patch is released. There is still a problem that the time period is longer and the user demand cannot be satisfied in time.
In the related art, there is still no solution proposed till now for the problem in the related art that the time period of re-customizing a diagnosis program for line diagnosis is too long to satisfy the user demand.